Even though I recognize that this is obviously working, I don't think that I follow it. Does it unconditionally go through every format string, even if the first one matches? That would explain why this needs to be at the end instead of the beginning. Would it be easier to reason about this if this inner match statement was in an inner function that can signal success by returning a success/fail value?

The reason this feels worth doing is that I believe that the entire function currently depends on the order of items in that format list plus the order of items in this match, and is therefore possibly pretty fragile in the face of refactorings. The tests will prevent people from introducing incorrect code, but I could see trying to interact with this code requiring a lot of understanding.

If you don't feel like experimenting with a refactoring, could you add a comment at the top of the possible formats loop (line 217) explaining the ways that these parts all fit together?

So the intention was to match on the first format that validly parses (the structure is a doubly nested for loop so the break statement is there when we've detected a mismatch between the format and the actual list of tokens and lets the control flow go to the next one), with the understanding that all of the potential formats with numbers are going to have numbers in HH MM order, so if the first number is >= 24, then we can just fail everything because we know it will never pass any format (as opposed to a token mismatch which could pass a different format)

I'll refactor a bit and add comments

thanks!